1. Field of the Invention
This invention relates to computer systems and, more particularly, to a method and apparatus by which a computer processor handles nested faults.
2. History of the Prior Art
A computer processor continually encounters circumstances in which it must halt the processing of a particular sequence of instructions to attend to some occurrence not usually encountered in the sequence. These occurrences are variously referred to as errors, exceptions, faults, and other terms which are often defined differently by different parties and under different circumstances. In general, such occurrences all require the processor to halt the sequence of instructions it is presently processing and take some action outside of the execution of the interrupted sequence.
As one example, an error in executing a particular sequence may require that the processor stop the execution, discard the results generated to that point, and move back to an earlier point in the sequence to begin reexecution. On the other hand, an interrupt may be generated by a modem signaling that data is arriving from circuitry external to the computer that is executing the sequence. Such an interrupt may require the processor to stop execution of the sequence, receive the externally-provided data, and then return to executing the sequence at the point at which it was stopped. There are many other situations in which a processor must halt its processing in order to attend to matters outside of the execution of an executing sequence, and all are subject to a number of the some of the same difficulties. Because there are many different situations, in this specification, the use of each of the terms fault, exception, error, and the like is intended to encompass all of these terms except where otherwise stated or made obvious from the text.
In prior art processors, the typical method of handling exceptions is to interrupt the sequence of instructions being executed, save enough information about the sequence and its execution up to its interruption to be able to return to the sequence and continue its execution, then transfer control of the processor to a software sequence of instructions for handling the exception (usually referred to as an exception handler), execute the exception handler to handle whatever needs be done to take care of the exception, retrieve the information about the interrupted sequence and its execution up to its interruption, and recommence execution of the interrupted sequence of instructions. Of course, in many situations, the exception will be such that the interrupted sequence cannot or should not continue so that the processor will be directed to some other sequence of instructions by the handler.
An exception or fault handler is typically a sequence of instructions stored by the computer which have been devised to carry out the processes necessary to service the particular interruption. For example, if a page fault occurs signaling that the data necessary for execution of a sequence of instructions is not in system memory, then the fault handler software to which the processor is referred is adapted to find the necessary information in long term memory and return a copy to system memory so that execution of the sequence may continue. If an interrupt signals that a modem is receiving external data which must be transferred to the computer essentially without interruption, then the fault handler software is adapted to see that all of the external data is received and stored without interference from the interrupted sequence of instructions.
Because such fault handlers are adapted to handle significantly different problems, they vary significantly from one to the next. However, since fault handlers are sequences of instructions which must be executed, these sequences are themselves subject to interruption by faults, exceptions, and the like. Consequently, it is possible to have what are typically referred to as nested faults, situations in which a fault handler is executing and itself is interrupted for some reason. Because such situations can occur, it is necessary to provide for their occurrence.
A primary difficulty is handling nested faults arises in saving sufficient information (state) so that the processor will be able to return after handling each of the levels of faults to the proper place in execution so that it may continue execution of the last interrupted sequence of instructions whether that sequence be typical code or fault handling code. Presuming that a nested fault occurs while servicing a first level fault, it is necessary that the processor before handling the nested fault save both state sufficient to return to the first level fault once the nested fault has been handled and state sufficient to return from the first level fault to the proper place in execution of the last interrupted sequence of instructions.
Prior art fault handling processes have typically accomplished this in one of two ways. According to a first method, the processor hardware is designed to save sufficient state to return from any level of nested fault the processor might possibly encounter and restart any faulting sequence. To do this, the processor responds to any fault at any level by storing sufficient state for whatever level of fault may later occur. Fault handling hardware is quite complicated. The need to save state for a number of levels of faults has further complicated and slowed the process of fault handling.
A second prior art resolution of the problem has been to provide hardware which does not save state on each fault and restore state on any return from fault. Such hardware is able to handle first level faults since the instruction at which the fault occurred is retained by the processor, but is not capable of handling nested faults by itself. To handle nested faults, such hardware is utilized with software fault handlers which include code for saving and restoring state necessary to handle any level of fault which might occur. This second method simplifies hardware fault handlers since only state necessary to return from a first level fault need be saved. However, the method requires much more complicated software fault handlers written to provide the extra steps necessary to handle or eliminate nested faults. These extra steps may be those necessary for saving and restoring state necessary to handle any level of fault which might occur. Alternatively, these extra steps may be steps necessary to preclude a nested fault from occurring. For example, steps to eliminate a nested page fault might reorder the instruction sequence so that the missing page is in memory before the attempt to access memory occurs. Should a nested fault occur, then the fault handler treats the fault as fatal and directs the processor to utilize the steps provided by this additional system software to eliminate the nested fault.
It is desirable to provide circuitry and processes by which a processor may accomplish fault handling more expeditiously than by any of these prior art techniques.